This section goes over the details of the claims-based identity model in ACS. Figure 1
illustrates the interaction between different components in a
claims-based identity model. With the terminology defined, it will be
much easier for you to understand the flow of information between
different parties in this model.
As illustrated in Figure 1,
several messages and tokens are passed back and forth between the key
parties in a claims-based identity model. Before the interaction
starts, prerequisites (listed as step 0) are required in order to make
the end-to-end scenario work. The following steps describe the flow of
information from the requesting user or application to the relying
party:
Step 0:
Two important prerequisites for claims-based identity to work are
completed in this step. First, trust is established between the relying
party (web service), ACS, and identity providers. The trust
relationships are refreshed on a periodic basis. The trust between ACS
and the relying party is established using a signing key. Second, an
administrator creates an issuer to identify service consumers and
defines the mapping rules between input claims and output claims in the
form of rules in ACS. The issuer key material is distributed to the
service consumer.
Step 1:
When ACS, the relying party, and identity providers are configured for
the claims-based identity model to work seamlessly, the service
consumer must use the issuer key material to acquire a token from ACS
in order to call the web service. In the current version (November 2009
CTP), the ACS supports three types of token requests:
Plain text: The service consumer sends an issuer key directly to ACS to authenticate the request.
Signed:
The service consumer creates an SWT, signs the token, and sends the
token to ACS for authentication. In this method, unlike with the plain
text request, the service consumer doesn't need to send an issuer key
directly to ACS. Typically, the signed token from the consumer includes
input claims that are then mapped to output claims by ACS and included
in the output token emitted by ACS.
SAML:
The service consumer acquires a signed SAML token from ADFS 2.0 or a
similar identity provider that emits SAML tokens, and sends it to ACS
for authentication. Intended primarily for ADFS 2.0 integration, this
approach requires that a signed SAML bearer token be acquired and sent
to ACS for authentication.
Step 2:
Based on the claims-mapping rules configured in ACS, ACS maps the input
claims received in the service consumer token to output claims specific
to the web service. The ACS then issues an SWT
consisting of output claims to the service consumer. ACS signs the
token using the key registered in Step 0. The mapping of input claims
to output claims makes ACS an R-STS. ACS abstracts the token-issuing
party from the token-consuming party by always emitting an SWT
containing output claims the web service expects.
Step 3:
Regardless of the method used to acquire the input token, ACS creates a
SWT and sends it to the service consumer. This SWT contains output
claims that the web service expects.
Step 4: The service consumer packages the SWT into an HTTP header and sends it to the web service along with the message payload.
Step 5:
The web service validates the token based on the secret key exchange
established in Step 0. The web service also validates the required
claims and grants or denies access to the resource based on the
validation outcome. There is no direct communication between the web
service and ACS during the method invocation. The only communication
happens during the periodic refresh of the secret key exchange.
Figure 1
may look complex initially, but when you go through the steps, the
claims-based identity is easy to understand. The next section puts the
claims-based identity model into an enterprise scenario perspective.
